![[セッションレポート] AI アプリ開発プロジェクトの始め方（AWS-45） #AWSSummit](https://images.ctfassets.net/ct0aopd36mqt/5YUWIDfDPXLtGwmcAEVK7u/772b9e509c709a0f53f51d6434f89d41/eyecatch_awssummit2024_session_english.png)
[セッションレポート] AI アプリ開発プロジェクトの始め方（AWS-45） #AWSSummit
2024.07.04こんにちは、森田です。
AWS Summit 2024で行われた「AI アプリ開発プロジェクトの始め方」のレポートをお伝えします。
オンデマンド配信は、 7月5日(金) までですので、見てない方はぜひチェックしてみてください。
セッション概要
AI を使って今までできなかったことをやりたいけれど、AI を組み込んだアプリ開発をどう始めてどう進めたら良いのか、どこかに落とし穴があるんじゃないかと不安を持つ方もいらっしゃるのではないでしょうか。
また、生成 AI の流れが来ていますが、従来の AI との使い分けや共存などにもお困りじゃないでしょうか。
このセッションでは、アプリ開発を始める前に考えておくべきことから、実際にアプリ開発をする際に便利な AWS サービスの使いどころの紹介、アプリ開発が終わった後も気にすべきことなど、AI 全般のアプリ開発ジャーニーにおけるビジネス＆Tech な内容をまとめてご紹介します。
スピーカー : 大渕 麻莉
所属 : アマゾン ウェブ サービス ジャパン合同会社 サービス&テクノロジー事業統括本部 Data&AIソリューション本部 機械学習ソリューションアーキテクト
レポート
一言まとめ
前提知識なしでAIや生成AIについて理解することができます。
AWSの機械学習系の試験対策として今後も見ておきたいセッションです。
AI基礎
AIの種類について
人工知能、機械学習、深層学習、生成AIの違いについて
人工知能内に機械学習が含まれており、機械学習の中に深層学習が含まれ、深層学習の中に生成AIが含まれるような関係
AIの特徴
入力が決まれば出力が一意に決まるタスクは、AIではない
例として、給与計算、あといくつ寝たらお正月なのか、など
AIの最大の特徴として、間違えることがある（精度 100%にならない）
なぜ間違えるのか？
入力が決まれば、出力の予測値が決まるが、一意に決まらない
機械学習は、単純な計算式・ロジックでは表現できない現象を表現するために使用される
また、時間と経過とともに、出力の予測値が変化するようなケースもあり、完全に予測することはできない
例として、昭和の時代のデータを使って訪日外国人の予測を行う場合、令和と昭和では、社会情勢の違いなどでうまく予測できない
間違いを減らす工夫
AIにデータを入力する前（前処理）
データのばらつきを抑える工夫
- ノイズの除去
- 入力の自由度を制限
- データ取得方法の改善
AIが予測値を出力した後（後処理）
最終精度を向上する工夫
- 複数AIの多数決
- 他手法の組み合わせ
機械学習のライフサイクル
- ビジネスゴールの設定
- 課題のフレーミング
- データ処理
- モデル開発
- モデルデプロイ
- モデル性能監視
時間の経過とともに、6→4に移動するなど、頻繁にフェーズを回していく
なぜビジネスゴールを始めにするか？
ビジネスゴールがないと、評価指標や評価データを作れない
ビジネスゴールがないと、どこまでモデルを開発していけば良いか判断できなくなってしまう
プロジェクトの見通しが立たない、プロジェクトが途中で終了となってしまうなどが起きる恐れがある
ビジネスゴールは、数値として定量的に測れるものにする
例: AIを使って、工場スタッフの作業員コストを50%にするなど
よくあるガッカリ体験
社内のDX部署が勝手にB部署の課題を考えて、アプリ開発を行う
ただ、実際には、B部署の課題にはなっていないかった
課題の見極め・課題の当事者を入れることは必須
AWSの機械学習スタック
大きく2つのグループに分けれる
- APIですぐに使える AI サービス
- 独自のモデル開発をサポートする機械学習サービス
AI活用パターン1
API ですぐに使えるAIサービスを自社アプリに入れ込む
| 項目 | |
|---|---|
| 学習データ | 不要 |
| 機械学習スキル | 低 |
| カスマイズ性 | 少 |
- Amazon Rekognition
- Amazon Transcribe
このサービスであれば、ライフサイクルのモデルデプロイ・モデル開発は不要になる
ユースケースとして
- Amazon Rekognitionを使った画像認識機能をアプリに導入
- 室内の人数カウント
- 顔認識での入室管理
精度評価と改善
ビジネスゴールに応じて、精度評価を行う
ビジネスゴールが、店内の混雑解消であれば、室内の人数カウントが10%ほど誤差が生じてもそこまで大きな問題とならない
ビジネスゴールが、席をピッタリに埋めて機会損失をゼロにしたいであれば、室内の人数カウントが10%ほど誤差が生じると、ビジネスゴールを満たせない
場合によっては、別の手段を検討する
例えば、席をピッタリに埋めて機会損失をゼロにしたいケースであれば、入り口にゲートを設置するなどより正確な方法など
AI活用パターン2
独自のモデルを開発して自社アプリに組み込む
| 項目 | |
|---|---|
| 学習データ | 必要 |
| 機械学習スキル | 中/大 |
| カスマイズ性 | 中/大 |
- Amazon Personalize
- Amazon Lookout for Vision
- Amazon SageMaker
従来のAIと生成AIの違い
従来のAI
数百から数千の学習データが必要とな
データの用意が大変である
生成AI
事前に大量のデータを使って、基盤となるモデルが作成されている
上記を自社で行う場合、時間・労力・コストが膨大にかかる
大規模言語モデルでは、質問に回答する形でのタスク実行が可能となる
Amazon Bedrock
ユースケースに応じて様々な生成AIが用意されている
従来のAIと生成AIの使い分け
翻訳であれば、Amazon Translateも利用できる
Amazon Bedrockでも翻訳可能である
一方で、生成AIでは、より柔軟な指示ができるため、「ぶっきらぼうな表現で翻訳して」などが可能となる
全部生成AIで良いのか？
| 従来の AI | 生成 AI | |
|---|---|---|
| 用途 | タスク特化 | プロンプトで各種タスクに対応可能 |
| レスポンス | 比較的高速 | ある程度時間を要する |
| 大量実行 | しやすい | 時間あたりの実行数の制限が厳しい |
| 出力の安定性 | 常に規定の形式で出力 | 出力形式の完全制御は困難 |
従来のAIの方がアプリに組み込みやすい、生成AIは考慮事項が多い
出力のカスタマイズ（プロンプトエンジニアリング）
意図的に回答させるために例を与える（Few-shot Learning）
出力形式を指定してそれに従うように命令する
プロンプトエンジニアリングの課題
所望の回答を得るために、プロンプトが肥大化して、プロンプトのサイズ制限を超える
API利用料金やレスポンスが遅くなってしまう
Fine Tuning
AIへ事前に知識を与える
よって、プロンプトでの入力が簡潔になったり、利用料金、レスポンスの速度問題の解決が期待できる
生成AIの注意点
大規模モデルでやっていることは、次に来る単語の確率を算出している
内容の正しさを考慮するメカニズムはない
生成AIの苦手
- 最新情報の対応
- 出力の制御
- 妥当性の保証
不適切なデータを入力したら出力も不適切に
Garbage In, Garbage Out
学習データやプロンプトに不適切なデータが含まれていると、不適切なデータが出てくる
対応策
Guardrails for Amazon Bedrock
アプリケーション要件と責任あるAIポリシーに合わせたガードレールを提供
- ビルドインコンテンツフィルタ
- マスクやブロック
- カスタムNGトピックの検出
Amazon Rekognition コンテンツモデレーション
画像に不適切な内容が含まれているかの検証
- Safe/unsafe 判断ではなく、各検査項目についての可能性を確率で出力
- 検査項目は3階層にカテゴリ分類され、独自の判定ロジックも可能
- サンプル画像を用意することで検出精度が向上
さいごに
AIの基礎から、生成AI、そしてAWSにおけるAIサービスの活用方法を学ぶことができました。
AWSでは、多くのAIサービスが迷ってしまいそうになりますが、本セッションを見ることでどのサービスを利用すべきかを判断することができそうです。
また、セッションの中で登場した Amazon Rekognition コンテンツモデレーションは面白そうな機能なので、今度機会があったら触ってみたいと思います。
